wondering if we should consider running this less frequently? I think it would depend on what @elastic/search-extract-and-transform prefer, but the scenario I picture is something like:

• this job runs once a week, or maybe even once every two weeks
• if Trivy identifies any vulnerabilities, a message is sent to a Slack channel, or a GitHub issue is created

let's see what folks think 👍

• if Trivy identifies any vulnerabilities, a message is sent to a Slack channel, or a GitHub issue is created

I think these notifications could potentially be a duplicate of existing Snyk issues detected on the official container image. What's the value added by these new notifications?

is Snyk going to scan the images produced by these CI jobs?
I think this PR is doing 3 things, but maybe doesn't need to.

1. switches our Dockerfile to use chainguard (has customer value)
2. Adds CI to validate the Dockerfile works (has customer value)
3. Adds CI to fail if a vuln is found (internal value, with indirect customer value)

I think (3) could probably be done separately, and reuse whatever machinery we use to scan other artifacts, especially since (1) and (2) will significantly cut down on false-positives that we'd have if we tried to do (3) on its own today.

The CI jobs in this PR do not push images to the docker registry, instead it relies on Trivy for vulnerability scanning, which runs within the context of the pipeline.

The alternative approach is to push the images to an internal namespace on the docker registry and request for these to be added to Snyk. This would result in duplicate reports though as we're already scanning the docker.elastic.co/integrations/elastic-connectors with Snyk built from the Dockerfile.wolfi image which is technically the exact same base OS build.

What's the value added by these new notifications?

...

which is technically the exact same base OS build.

These are really good points that I hadn't considered. Given that with this PR we are:

• switching the Dockerfile to become distroless, and making the resultant image considerably more secure
• making the Dockerfile essentially the same as the Dockerfile.wofli, the latter of which produces the images that are pushed and scanned by Snyk
• adding nothing in the Dockerfile except the bare minimum that we need to run connectors (assuming we get rid of git and make 👍)

... then I actually don't see much value in adding the Trivy step (let alone adding notifications based on its results). I wish I'd had these realizations sooner, apologies @kostasb.

What do you all think?

@kostasb thanks, I like the idea of leaving the Trivy step there, but not having it send any notifications. But I'll defer to E&T folks (@seanstory @artem-shelkovnikov) to say what they prefer 👍

I have no objection to leaving it (without notifications) but also I don't think a human will be manually looking at the outputs often. So if we're ok as treating it essentially as a source of debug logs that may or may not be examined, great.

I understand the following might be a big direction change for this PR, but considering the feedback above, I think it might be worthy to explore: what if, instead of adding a new pipeline (with informative value only), we add the Trivy scan step to the existing pipeline? I think the informative value would be higher for developers working in PRs: the Trivy scan would be part of their feedback loop, and not something relegated to a different pipeline.

Similarly to what we did for ent-search, I would run the Trivy scan step in PRs to main, and on merge on main and other current release branches. What do you all think?

Merging the extensible Dockerfile build/test/scan steps into the main pipeline makes sense to me, we can proceed this way if the team agrees.

I pushed a commit that merges the extensible Dockerfiles pipeline into the main pipeline (easy to revert if the team @seanstory @artem-shelkovnikov has a different opinion after all).

As a bonus point, this also enables testing as part of this PR (the new dedicated pipeline wouldn't be picked up until after merged).

I think we are not going to get a lot of value from these steps, given that Dockerfile.ftest is almost equivalent to Dockerfile.

So I'm wondering: what if instead (maybe in a different PR, as a follow-up) we delete the two .ftest Dockerfiles and we try to live with only two Dockerfiles instead of four (Dockerfile and Dockerfile.wolfi), and we move the RUN .venv/bin/pip install -r requirements/ftest.txt command out of the Dockerfiles, where we actually run those specs?

That makes sense, I'll remove the ftest builds/tests/scans from this pipeline and follow up with an issue about replacing/removing the ftest dockerfiles.

Created an issue for it: https://github.com/elastic/search-developer-productivity/issues/3611

@oli-g I just wanted to bring up an issue I foresee with this suggestion:

In this current PR here we remove make and then run the image as nonroot, which doesn't allow installing packages beyond what's already available.

We won't be able to run the functional test steps on top of this image as these require make. We'd need to build another container image layer with this Dockerfile as base, to re-install make in order to run the functional test.

Got it, I missed this "little detail"... thank you! I guess we'll have to find a different approach, or leave things as they are for now. We'll discuss it in the new ticket.